The Linux kernel has changed the layout of the iov_iter struct a few times since v5.8 (the minimum version we support). In particular:

• until v5.13, the iterator type was represented by an unsigned int bitmask struct member called type. The bitmasks were defined by the iter_type enum. (reference)
• from v5.14, the type bitmask was replaced with an 8-bit member called iter_type. This is no longer a bitmask, instead it carries a simple enumerator value. The iter_type enum was changed so that it is no longer defining bitmasks. (reference)
• kernel v6.0 introduced a new iterator type in iter_type called ITER_UBUF - it was the last enumerator in the enum definition and was assigned the value of 6. (reference)
• kernel v6.5 removed ITER_PIPE and reassigned ITER_BUF to 5 (reference)
• kernel v6.7 reordered the iter_type enum, assigning ITER_UBUF a value of 0, and ITER_IOVEC a value of 1 (previously it was 0). (reference)

Beyla wasn't correctly checking for the type vs iter_type distinction, which caused the the iterator type to be wrongly resolved to 0 in kernel versions < 5.14. It was also assuming that the value of ITER_UBUF to be 6, which was no longer true for kernels above 6.10. These caused Beyla to wrongly parsing the incoming msg header buffer, thus failing to extract races.

The version of the cilium/ebpf component has been upgraded to v0.16.0 in order to address cilium/ebpf#1348 (git commit)

This issue is potentially related to #1055

Tested on the following kernel versions/distros

• 5.10 - debian
• 5.14 - opensuse
• 6.1 - alpine
• 6.4 - opensuse - note: OpenSuse 15.6 has a custom patched kernel (6.4.0-150600.23.7) with backported changes from v6.5 which removes ITER_PIPE
• 6.6 - alpine
• 6.10 - arch